Technical Field
The present invention relates generally to session management in an enterprise computing environment in which users access back-end resources through a front end point of contact, such as a reverse proxy or web server plug-in.
Background of the Related Art
Web portals centralize access to information, applications, and services for employees, customers, or partners. They deliver a consolidated view that lets users access the most important electronic resources of the organization using a standard technology (a web browser), simply and efficiently. Within a Web portal or like environment, typically a proxy or web server acts as a front-end “point of contact” to a set of back-end applications or application components. In this type of environment, the ideal scenario is that the mechanism used to provide authentication and session management at the web portal layer should also provide these functions for any back-end applications that are included in a consolidated view. However, as existing applications (each with its own authentication/session management) are moved into this environment, it is often not possible to turn off such authentication/session management functionality.
In this type of environment, approaches to session management typically have each back end application or application component requiring its own session state management, and each such application or component may implement its own session management technique. Where an end user is accessing multiple applications within a single enterprise, his or her browser ends up managing independent session management items (often as many as a different item per application). Typically, in this environment, these items are HTTP cookies, as the behavior of such cookies (although not intended for session management) provides reasonable session management. In particular, these cookies typically contain information (such as a JESSIONID value) that is managed by the application that sets it. Given this operating environment, consider the scenario where there are several applications, each managing their own JSESSIONID cookies. If a user ends his or her session at one application, this action typically will have no effect on the browser's session(s) with other applications. While this may represent desired behavior, this independence of session management techniques has undesired consequences when a special session management component is placed in front of these applications.
In particular, it is known in the prior art to enhance security of a Web portal by integrating an enterprise security product with the portal. Security refers to the portal's ability to authenticate users and authorize access to the Web resources. The quality of security services provided by an enterprise portal typically rests in the degree of integration between the portal service and an associated enterprise security product. One such enterprise-level security product, known as Tivoli® Access Manager (TAM), from IBM®, provides a single point-of-user authentication and authorization administration, together with Web-based single sign-on. This type of access manager provides authentication and authorization to Web-based resources, and it provides standards-based APIs that allow back-end Web application servers to access the access manager's security services.
Now, consider an environment using a product such as Tivoli Access Manager to provide authentication, session management and authorization functionality. As noted above, TAM provides a reverse proxy and/or web plug-in that provides session management functionality and that includes authorization functionality as part of this session management. Authentication is handled by TAM, meaning that TAM collects a user's authentication credentials, evaluates them, and establishes a session, including some form of session management functionality (such as a session cookie). To provide a user with the advantages of this consolidated environment, TAM then provides a single sign-on solution for the user by asserting authentication credentials (such as username/password) to the back-end applications. This allows the back-end application to be added to the portal environment without modification; in other words, because it is still able to execute the authentication process, changes to the application (e.g., to remove or turn-off this functionality) are not required. The side effect of this approach, however, is that the application will continue to employ its existing session management techniques. As noted above, however, the application may have its own session management techniques, including JSESSIONID cookies. Thus, while this environment may provide the user with a single point of authentication and may act as the “authoritative” session management authority, the back-end applications will often have their own, additional session management techniques that are used at runtime. The authorization session management source (e.g., TAM) is able to create a session, but it is not able to provide further session management at the granularity of the back-end applications, where duplicate session management is provided. Thus, for example, when a user logs out of TAM, the access manager has no way of indicating this log off to the back end applications, nor of “killing” these JESSIONID cookies so that further access to back end applications is possible.
This has several undesirable consequences. Consider a user, Alice, who logs into TAM and accesses a back end application A, where application A sets its own JSESSIONID cookie for local session management purposes. If Alice logs out of TAM, her TAM session cookie is destroyed but her back end JSESSIONID cookie set by application A is not. Thus, if Alice logs back into TAM at a later time (namely, while application A cookie is still valid), she will resume an existing session with A. This scenario becomes even more alarming when one considers behavior in a “kiosk” style environment where these session cookies are maintained by a browser that is shared by many different people. Now, if Alice logs out from TAM and Bob, who has been waiting to use this Internet kiosk, logs in, Bob inherits Alice's application A JSESSIONID cookie by virtue of the reuse of the browser. This situation is illustrated in the UML sequence diagrams shown in FIG. 1 (for Alice) and FIG. 2 (for Bob, following Alice's log out from application A). In particular, these diagrams show representative message and information flow within this type of operating environment in which the back end application A is accessed (first by Alice, and then by Bob) via a shared browser. Obviously, this scenario is quite dangerous as it has the potential to expose to Bob Alice's resources (such as her bank account).